1. Field of the Invention
The field of the invention relates to development and testing. More particularly, the field of the invention relates to the development and testing of software.
2. Description of the Related Technology
An embedded device typically includes a microprocessor and application software. The application software runs under the control of a real-time operating system (RTOS) and is typically partitioned into one or more threads. A thread is an independent unit of executable software that shares the control of the microprocessor with other defined threads within the embedded system. In many embedded devices, a thread is allocated its own stack space, given a “priority”, and assigned other resources that enable the thread to run as an “independent” entity. Stack space is a section of memory reserved for temporary storage of local variables. Priorities are used by the RTOS to determine which thread gets control of the microprocessor if more than one thread is waiting. Resources can include miscellaneous items such as queues, flags, etc., that are required by the RTOS to manage a thread. Other common terms used for a thread are “task” and “process.” A process also implies a separate address space which protects different processes from adversely affecting each other. An example of a process running on a desktop computer using Microsoft's Windows Operating System (OS) is Microsoft Word.
A common method for threads to communicate with each other is via a messaging application programming interface (API) that is provided by the operating system. A message typically includes an event and optionally a block of data that is sent between at least two threads. For example, a thread (“the sender”) builds a message and invokes a specific API from the RTOS. The RTOS notifies the other thread (“the receiver”) that some type of event has occurred. The receiving thread then reads the incoming message. Another common method for threads to communicate is via a function call. Using a function call provided by one thread can be invoked by another thread. Likewise functions can be called by other functions that co-exist in the same thread. Other common terms for a function include a subroutine, a procedure, or a method. As used herein, the term “communication interface” is intended to embrace any interface for communicating data between two threads, such as via either messaging or remote function call communication.
There are several problems associated with known development and testing systems for embedded devices as described above. First, known testing systems require the use of the embedded device that has an operational RTOS to test the communication interfaces of the threads and to test the execution of the threads themselves. Disadvantageously, known systems do not have the ability to simulate communication interfaces and the corresponding threads that support them.
Second, when using more than one platform to host running threads, there is a compatibility problem representing interfaces on different machines. Different types of machines store messages differently in their respective memory space. Known testing systems do not automatically format data for transmission to different platforms. An example of incompatibility between two computers is when one computer stores a 16-bit integer (2 bytes) with the least significant byte in low memory (Little Endian) and the other computer stores the least significant byte in high memory (Big Endian). When the applications want to exchange this 16-bit integer, the value of the integer is interpreted differently depending on the computer.
Third, known systems require the creation of a custom desktop tool that can communicate with the embedded software. The process of building interface functionality for a specific embedded application is a time consuming and manual process. The desktop tool and the embedded software both require manual updates to their application to enable them to communicate with each other. Thus, there is no seamless and automatic access via a desktop tool to the interfaces for an embedded software application.
Fourth, desktop applications developed in other programming languages that are incompatible with standard C/C++ interface definition files cannot interact with the embedded computer seamlessly. Typically, interface definition files define the format of the messages expected by the embedded software. Languages such as Visual Basic, LabVIEW, etc., cannot use standard C interface definition files that define the format of the interfaces. Thus, software engineers that use these languages cannot test the threads executing on the embedded device.
Thus, there is a need for improved devices for development and testing of embedded software that do not have the foregoing limitations.